home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000165_misckit-reques…aska.et.byu.edu_Wed Apr 6 12:41:34 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  3KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA11378; Wed, 6 Apr 94 12:41:19 -0600
  4. Received: from YVAX2.BYU.EDU by alaska.et.byu.edu; Wed, 6 Apr 1994 10:53:26 -0600
  5. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-7 #4169)
  6.  id <01HAUOVWF0XCR5NACH@yvax.byu.edu>; Wed, 6 Apr 1994 10:53:09 MDT
  7. Received: from gac.edu (nic.gac.edu) by yvax.byu.edu (PMDF V4.3-7 #4169)
  8.  id <01HAUOVNYROGHSQ4QT@yvax.byu.edu>; Wed, 6 Apr 1994 10:53:00 MDT
  9. Received: by gac.edu (NeXT-1.0 (From Sendmail 5.52)/GAC-1.0.R9309061)
  10.  id AA04537; Wed, 6 Apr 94 11:52:01 CDT
  11. Date: Wed, 06 Apr 1994 11:52:01 -0500 (CDT)
  12. From: kane@gac.edu (Chris Kane)
  13. Subject: Re: Comments on MiscAgent
  14. To: zet@cip.e-technik.uni-erlangen.de
  15. Cc: misckit@byu.edu
  16. Message-Id: <9404061652.AA04537@gac.edu>
  17. Content-Transfer-Encoding: 7BIT
  18.  
  19. Juergen Zeller <zet@cip.e-technik.uni-erlangen.de> writes:
  20. > As Christopher pointed out, MiscAgent would provide a easy to
  21. > learn framework for any common Application.
  22.  
  23. Well, not an *entire* framework, not everything.  But another
  24. piece.  Not, in itself, for instance, a document controller system.
  25. A document controller system has demands placed on it that I
  26. haven't envisioned MiscAgent satisfying.  It's directed more
  27. towards (as you say later) the miscellaneous user-interface
  28. windows and panels and related classes.  The model of panels==actors
  29. (in the real-world sense) and MiscAgent==talent agency works
  30. well, I think.
  31.  
  32. > A looking ahead design of the MiscAgent will nearly be impossible
  33. > due to the Kit's very nature. A MiscAgent as a quite informal
  34. > framework could lead to a problem like the one stated above:
  35. > Nobody knows exactly what's happening and - even more important -
  36. > the exact point where it happens can hardly be found by a new or
  37. > different developer.
  38.  
  39. Again, I think that framework is a bit too strong of a term for
  40. this.  The root and manager of a heirarchy of classes dedicated to
  41. a particular purpose, perhaps.  And a very generic one--an application
  42. would contain an instance of MiscAgent, but I don't expect that
  43. messages would be sent directly to it by the programmer.
  44.  
  45. Documenting the capabilities of classes managed by the MiscAgent
  46. is the responsibility of the programmer and/or writers of the
  47. specification and design of an application.  The problem described
  48. (confusion in a project's development) seem to have resulted from a
  49. lack of software engineering methods in the specification and design
  50. phases of the project, not from the particular functionality of
  51. any piece of the software.
  52.  
  53. And on my original note:
  54. Another possibility, perhaps better than forcing agents to be
  55. subclasses (at some level) of MiscAgent, would be to have a protocol
  56. which is conformed to by classes/objects desiring to be "managed".
  57. This begins to hint at a wider scope for Misc*Agent than class
  58. and .nib loading and message forwarding, though, which is not my
  59. intent at this time.
  60.  
  61. My hope would be that people would think about what sort of features
  62. such a thing as I described would have, and how it would behave,
  63. and perhaps make lists of their thoughts.  No one or two people
  64. can think of everything (not in the short term, at least :)).
  65. Such lists can be emailed to me, if you find you have something you
  66. want to share.
  67.  
  68. Christopher Kane
  69. kane@gac.edu